Towards a Product Line of Interpreters: an Experiment with Small Functional Languages

ion to deal with missing information. Consider the following three slightly different implementations of an identifier reference in the F1WAE languages. The semantics of an identifier reference can: • in case of explicit semantics, produce an error indicating that the identifier is not bound; • alternatively, also indicate that an error value is necessary by parameterizing its semantics with a lambda that provides such a value; • in case of deferred semantics, simply assume that the value is available (abstract from its definition site) and lookup the value. Upon composition of identifier references in a language, one does not need to distinguish between those three implementation variants. LTS provides an abstraction from these three implementations and can uniformly handle them, because in essence in all cases a value is requested that is not available. TOWARDS A PRODUCT LINE OF INTERPRETERS: AN EXPERIMENT WITH SMALL FUNCTIONAL LANGUAGES 4 In some cases semantic dependencies have to be explicitly dealt with. Let us revisit the semantics of a function application. The implementation of its semantics is quite different depending on whether substitution or an environment is used. Following the strict discipline of LTS to modularize the semantics, a function application in the F1WAE language could adopt an operational semantic style using the abstract notion of a binding. Hence, the semantics consists of these three steps: 1) extend the evaluation state with a new binding, 2) interpret the body, 3) revert the evaluation state by cancelling the binding. This formulation allows developers to reuse the semantics of function application regardless of explicit or deferred semantics. In case of explicit semantics: 1) change the evaluation state to a new program where the identifier is substituted, 2) interpret the body, 3) do nothing, as the evaluation state does not have to be reverted In case of deferred semantics: 1) change the evaluation state to an extended new environment containing the identifier, 2) interpret the body, 3) revert the evaluation state to the environment where the new binding is removed To conclude, semantic dependencies on shared interactions can be avoided by raising the abstraction level of the implementation of the semantics. As we have demonstrated, for some dependencies LTS provides built in semantics to implicitly abstract from these dependencies, for other dependencies explicit care is needed. Future work has to determine whether new abstractions can be implicitly supported and how. 5.3 Dependencies on other language features The case where semantics also depend on other language features to yield a coherent overall language semantics is the most delicate task. The reason for this is that subtle differences occur deep inside the semantics of a feature and possibly many features. The challenging part is twofold: (a) to specify the correct locations and (b) to specify the changes in semantics without violating the modularity of language features. Note that the latter is not simply a restriction but rather a fundamental requirement to avoid brittle language extensions. In the example given in the previous section, lazy evaluation impacts quite a lot on other language features. More so, the places where strictness applies are difficult to assess. Our goal is to be able to declaratively specify the locations [CD08], instead of depending on low-level implementation details by relying on mere syntactical patterns [GB03]. For the example of strictness, strictness has to be applied whenever the interpreter executes a function of the host language4. However, this definition only covers a subset of all the places in the interpreter. To complement this definition, we are increasing the abstraction level of the semantics away from low-level implementation details so as to better expose the assumptions taken. In case of strictness, we could require developers to tag the operations executed by the interpreter. With these tags we could indeed declaratively specify all locations where strictness applies.